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ABSTRACT 


The NASA Computer Security Program la based on the fundamental 
premise that it Is not possible to have a risk-free data 
processing operation. Risks, therefore, must be managed. This 
report presents guidance to NASA computer security officials for 
developing risk management plans. An overvlev of ADP security 
risk management provides a discussion of the six components of 
the risk management process: (1) risk analysis, (2) risk 

reduction analysis, (3) management decisions, (4) risk reduction 
action plans, (5) Implementation and maintenance of plans, and 
(6) revlev and audit of plana. 
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1. INTRODUCTION 


The Office of Managi'aent and Budget (OMB) Circular A- 71, 
TranealtteL Memorandum No. 1, dated 27 July 1976, requires each 
agency to develop end iapleaent a coaputer security prograa. 
This docuaent provides guidance for developing risk aenegeaent 
plena which ere one aspect of the NA3A Coaputer Security 
Program. The davelopeent, iapleaentetion, end aeintenence of 
risk aenegeaent plans follow the performs net of a Date 
Processing Installation (DPI) risk analysis or a sensitive 
application evaluation and certification process. Bisk 
aanageaent planning is perforaed to assure that ADP security 
risks are prudently managed since it is not possible to have a 
risk-free data processing environment. 

NASA is well into the coaputer security prograa development and 
iapleaentation process in compliance with OMB Circular A-71, TM 
Mo. 1. NASA Management Instruction (NMI) 2410.7, ‘'Assuring 
Security and Integrity of NASA Data Processing’* has been 
issued; Center-level aanageaent instructions on coaputer 
security have been issued; Coaputer Security Officials (CSOs) 
st the Center, DPI and applications levels have been appointed; 
and coaputer security guidelines have been published to address 
the performance of risk analysis, definition of security 
requirements for applications software, evaluation/ 
certification of existing applications software, ADP 
contingency planning and computer security training. Also, a 
number of DPI risk analyses and application certifications have 
been accomplished. 

One of the next st ps in the implementation of the NASA 
Computer Security 'rogram is to develop guidance on managing 
the security risk* associated with their data processing 
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installations and applications systens. The guidance provided 
herein nay be nod if led by the NASA Centers, individual NASA 
DPIs, or, with NASA approval, by the NASA contractors who 
develop risk aanagenent plans for NASA organisations. The 
guidance and risk aanagenent proceaa aay alao be aodifed to 
suit the needs of a DPI or an application coaaensurate with the 
nature and degree of identified riak. 

1.1 Purpose 

The purpose of this docuaent is to provide NASA Center, DPI, 
and Sensitive Application CSOs with guidance on the 
preparation, lapleaentatlon and aalntenance of risk aanageaent 
plans (IHPs). These plans aust be adequate to aeet federal and 
agency requlreaents and provide a systematic end flexible 
approach to aanaglng computer security risks. This docuaent 
addresses the risk aanageaent planning which should be 
accoaplished at the data processing installation, application 
software, and Center levels. 

1.2 Scope 

The guidelines presented in this docuaent provide a systeaatlc 
proceed to assure that the security -risks reported to NASA 
aanageaent are acted upon In an orderly and tiaely fashion, 
lapleaentatlon of controls should be accoaplished according to 
a cohesive plan approved by top aanageaent. The guidance is 
applicable to the aanageaent of security risks that have been 
identified during a risk analysis performed at a data 
processing installation or during the evaluation/certification 
of a sensitive application. 
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1.3 Key Action I teas In Rial Management Planning 


Computer security officials, In thalr rola as risk managers or 
risk management planners, muat accomplish a series of actions 
to assure that DPI and application risk management plans ere 
both comprehensive and usable. Lack of proper planning may 
result in the Implementation of Ineffective controls. Improper 
Implementation of controls, or a plan that la not responsive to 
changes in mission, organization, technology, and personnel. 

The action Items that should be accomplished by risk management 
plan developers. Implemented, and malntalners are: 


1. Define the Risk Environment .* Review and document 
current equipment and facility configurations; identify 
sensitive and critical applications; and understand the 
data processing operating environment. 

2. Define the Categories of Risk .* The threats that can 
adversely impact a DPI or an application should be 
identified and documented. 

3. Evaluate Occurrence of Risks .* Each documented risk 
should be evaluated with respect to its likelihood of 
occurrence. The rationale for the likelihood should 
also be documented for future reference. 

4. Assessment of Risk Occurrence Im-.act .* Assess and 
document the Impact on the DPI or application for each 
risk, should it materialize. 

5. Document Risk Reduction Decisions . The decisions made 
by management following a DPI risk analysis or an 
application evaluation should be documented. The 
controls selected for implementation, budgetary 
limitations, and the milestones set by management 
should be Included in the documentation. 

6. Develop Risk Reduction Action P lan . The risk reduction 
action plan details the specific controls as action 


*The first four action items collectively comprise a risk analysis 
or evaluation/certification activity. 
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items to be implemented. It also detsils the schedule 
for internal design development, installation, and/or 
procurement. The plan also establishes responsibility 
for the accomplishment of each action item. 

7. Implement the Controls . Implementation will involve 
Integration of nev/revised controls Into existing 
processes. Personnel should be briefed or trained in 
the operation of new controls. The rationale and 
benefits to be derived from implementation should also 
be explained. 

8. Develop Risk Management Plan Maintenance Procedures . 
Changes in technology, organizations, and individuals 
will probably cause changes to be made in the security 
requirements of the DPI and the applications. 
Haintenance procedures should be developed to ensure 
that the risk management plan remains a dynamic and 
viable management tool. 

9. Review and Audit . The risk management plan must be 
reviewed periodically to determine if action items are 
being accomplished in accordance with the plan. 

Changes in facilities, equipment; organization, or 
personnel may require modification to the r±nk 
management plan. Changes may also indicate an update of 
the last risk analysis and application evaluation 
should be considered. 


1.4 Overview of the Report 


Section 2 provides an overview of risk management concepts and 
the risk management planning process. Section 3 presents a 
discussion of the steps to be accomplished In developing DPI, 
application and Center risk management plans. Section 4 
addresses the area of risk management plan maintenance. 
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OVERVIEW 0? RISK MANAGEMENT 


■ASA Handbook (NHB) 2410.1, Computer Resourced Management, 
Appendix J, states: 


... the NASA Computer Security program la baaed on the 
fundamental premise that It la not poaalble to have a 
rlak-free date processing environment. Risks, 
therefore, t c be managed. They must be 
appropriately defined, categorized aa to likelihood of 
occurrence, and assessed as to the resultant 
consequences If they occur. Actions must then be 
taken to allocate resources to alt.'M.ze risks In a 
manner that provides the best overall security. 


Risk management is a comprehensive concept Tor defining and 
analyzing the threats of which we are aware and assisting 
management in optimizing the amount of security return on the 
investment dollar. The risk management process attempts to 
answer the following questions: 

e What Is at risk and what needs to be done? 

a What security controls are available to reduce the risks? 

s What security controls will provide the best return on 
Investment? 

e Who is responsible for Implementation? 

a How will controls be implemented and over what time 
frame? 

S How effective are the controls once they are Installed? 


The AD? security risk management process consists of six major 
phases : 


1. Risk. Analysis 

2. Risk Reduction Analysis 
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3. Hwn«awt Decision 

4. OmlopMat of Klok Icdoetloa Action Plano 

3. Implementation and Maintenance of Controls 

4. Eeelev and Audit 


The ADP security rink sanastsent proceas provides for 
progressive Iteration since the risk environment la subject to 
change. Figure 2-1 depicts the process, the questions which 
are answered In each phase, and the Iterative nature of the 
process. The ADP security risk management process is based on 
the fundamental risk management concepts and definitions. 

2.1 Risk Management Concepts 

In "An Anatomy of Risk,' William D. love introduces the concept 
of risk with the following statement: 


The only certainty In life la death; uncertainty lies 
in when end how death occurs, awl whe.ner It is final. 
Man strives to delay its onset and extend the quality 
of life in the interim. Threats to these objectives 
involve risks, some natural, some mac-made, some beyond 
our control, and some controllable. 


kowe further states: 


Everyone Is constantly subjected to an array of risks, 
both as an Individual and as a member of various 
societal groups. Generally these risks are accepted 
qualitatively, even questioned and deliberated In this 
manner, rather than analyzed quantitatively. As a 
rule, risks are quantitatively assessed only in 
classic gambling games (e.g., playing the odds at 
craps). In business and Insurance decisions, and in 
some governmental regulatory actions. 
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FIGURE 2-1 

THE ADP SECURITY RISK MANAGEMENT PROCESS 
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In the NASA AEP environment, quantifying rlaka la one of the 
ntceaaary activities In determining which threats should be 
controlled . 

2.1.1 Risk Definitions 


Allen Wlllet In "The Econonic Theory of Risk and Insurance" 
defines risk as "the objective uncertainty regarding the 
occurrence of an undesirable event." Prank Knight In "Risk, 
Uncertainty and Profit" defines risk as "neaaurable 
uncertainty." Derenburg, Ellers, Malone, and Zelten In "Risk and 
Insurance" define risk as "uncertainty of loss." All of these 
definitions involve soae aspect of uncertainty. 

Rowe states, "Uncertainty exists in the absence of Information 
about past, present or future events, values, or conditions ... 
the basis of uncertainty is the absence of Information about parts 
of a systea under consideration." In the data processing 
environment, the process employed to reduce uncertainty is risk 
analysis. 

2.2 Risk Analysis 

Risk analysis attempts to answer the question, "What is at risk?" 
PIPS Pub 65, "Guidelines for Automatic Data Procesalng Risk 
Analysis," defines ADP security risk analysis as follows: 

The aim of risk analysis Is to help ADP management 
strike an economic balance between the Impact of risks 
and the cost of protective measures. It serves to 
point out the risks which exist; ... An analysis 
shows the current security posture of ADP processing in 
an organization; It then assembles the basic facts 
necessary for the selection of adequate, cost effective 
safeguards. 
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A quantitative statement of risk is the result of two 
considerations: (1) the damage that can result from an 

unfavorable event, and (2) the likelihood that such an event 
will occur. 

An analysis of risk Involves the following procedures: 

s Identify the scope of the risk envlronoent and determine 
what Is at risk. 

e Identify the flaws In the environment that night permit 
the threats to materialise. 

a Estimate the likelihood that the threats will occur. 

s State the cost of loss that could be Incurred if the 
threats to the risk environment were to materialise. 

It should be understood that risk analysis, or the reduction of 
uncertainty, does not of Itself reduce risk. Using the 
information gained from the risk analysis, a further analysis 
can be performed to determine what measures can be taken to 
reduce the identified risks and potential losses. 

2.3 Risk Reduction Analysis 

Klsk reduction analysis can be viewed as an analytical process 
that attempts to answer the following questions: what controls 
are available to reduce risks, and which controls will provide 
the best security return on Investment? The risk reduction 
analysis determines the cost of potential controls Including 
both the implementation and maintenance costs. A cost-benefit 
analysis should be conducted to estimate the reduction In risk 
If the safeguards were to be applied. The final step In the 
risk reduction analysis Is to recommend a set of controls to 
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management. Th* recommendations should Include a return o- 
investment celculetlon which provide* e retio of the expected 
lose reduction to the annual control cost. 

2.4 Management Decision* 


The choice and use of nethods of treating risks are management 
decisions. In the government environment, management has four 
options for dealing with known risks: 


1. Option 1 ~ Eliminate the Bisk . The objective under 
this option is to eliminate vulnerabilities or 
potential vulnerabilities as early as possible in the 
system life cycle. At best this takes place early in 
th* design and development of a system. 

2. Option 2 - Loss Prevention . Controls should be 
implemented to prevent loss as far as possible when 
risks cannot be eliminated due to technological or 
operational reasons. 

3. Option 3 - Loss Limitation . Loss limitation should be 
considered when prevention is not possible. The task 
of loss limitation is to limit the extent of loss to an 
acceptable level. 

4. Option 4 - Accept the Risk . Management nay decide to 
accept the risk and the consequences when the cost of 
loss is not significant, the cost to prevent or limit 
loss exceeds the potential loss, or the probability of 
loss is judged to be sufficiently small. 


After the risk analysis and risk reduction analysis results are 
presented to management, decisions are made regarding the 
specific controls to be implemented. While the risk analysis 
team makes recommendations based on security need and return on 
investment, management should make the final selection based on 
its broader view of organizational mission, goals, and 
objectives. Management must designate priorities for the 
implementation of controls in consideration of other 
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rtqulrtMiiti for staff and budgetary resources, planned 
upgrades or replacement of equipment, planned aajor changes to 
existing systens and the developaental activities for new or 
replaceaent ays teas. Management should also aake the initial 
determination regarding which organisational eleaents and/or 
personnel will be responsible for the lapleaentatlon of 
controls and provide direction and guidance on the schedule for 
lapleaenting thone controls. In cases where the coordination 
or approval of other organizational and/or management personnel 
la required, management should assure that such coordination or 
approval la obtained. All decisions made by management 
concerning the risk analysis results should be documented for 
use by the risk management plan developers. 

2.5 Development of Rlak Reduction Action Plans 

After management haa determined which security controls will be 
Implemented, the tasks leading to Implementation must be 
accomplished. The risk reduction action plans must Identify 
what controls are to be implemented, the systems and processes 
affected, the persons responsible, and the schedule for 
Implementation. Depending on the type of control to be 
implemented, procurement activities may have to be initiated or 
Internal design and development activities planned. Regardleaa 
of whether controls ere procured from outaide sources or 
developed internally, resources (personnel and money) will have 
to be obtained and allocated. In either case, the risk 
reduction action plan is the tool that will assure that 
security controls are implemented in a systematic manner. 
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2.6 Implementation and Maintenance of Control* 


Implementation of lecurity control* will necessitate soae 
change In proceasea, functions, or reaponalbllltlea. 

Therefore, eech person who la affected by any changes due to 
the Implementation of controls must be convinced that: 

(1) there la a problem, ( 7 .) they can do something about It, and 
(3) It Is advantageous to do so. Prior to Implementing new 
controls, any changes In operations should be coordinated with 
affected personnel and additional training may also be 
required. Where possible, controls should be thoroughly tested 
to assure that they are operationally and technically sound. 
Once Installed, controls should be maintained In accordance 
with the risk reduction action plans. When the risk 
environment changes, the maintenance process must be flexible 
enough to handle such changes. 

2.7 Review and Audit 


There should be a reasonable balance between the risk 
environment and the protection against such risks. Changes in 
operational processes, technology, and types of applications 
may result In materialization of new r or different risks. Some 
risks may become less significant. Periodic reviews of 
security controls should be conducted to alert management to 
Ineffective, non-functioning, or unneeded controls as well as 
Indications of where new risks exist. Depending on the nature 
and magnitude of changes, an update to the previous risk 
analysis may be Indicated. 

Previous NASA guidance provided methodologier for conducting 
and documenting risk analysis and evaluating/certifying 
existing applications. The remainder of this document will 
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provide guidance on an approach for aesurlng that the needed 
controle Identified In riek analysis and application 
evaluation/certification are successfully lapleaented and 
aalntalned. 


% 
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3. RISK MAl.'A^LMENT PLAN DEVELOPMENT 


Appendix J, NUB 2410.1, states that aound management of riaka 
da nand a docuaantatlon In Cha (ora of a rlak aanagtaent plan 
(BMP). The davalopnanc of an BMP follows tha conduct of a DPI 
risk analysis snd/or a sensitive application evaluation/ 
certification. An BMP Includes a description of the risk 
environment, categorisation of the risks to the risk 
environment, an evaluation cf risk occurrence, the lapact on 
the risk environment should the risks materialise, the degree 
to which risks can be controlled, and the actions which have 
been or are being taken to reduce risks. The development of an 
BMP will draw heavily upon the information that was collected 
or generated during the risk analysis or sensitive application 
evaluation. Separate guidance is provided for DPI and 
sensitive applications because separate methodologies are used 
within NASA to evaluate the risks to data processing 
installations and sensitive applications. 

3.1 Preliminary Planning 

As indicated previously, the guidance presented herein presumes 
that a risk analysis has been conducted at a data processing 
installation and/or an evaluation has been performed on an 
existing sensitive application. Although no reference is 
specifically made to new applications, it should be noted that 
(1) risk management plans should be developed for such 
applications and, (2) the development process described herelu 
is sufficiently generic so that it can be employed by personnel 
developing BMP's for new applications. In addition to having 
accomplished a DPI r'sk analysis, the following guidance 
assumes that the risk analysis results have been presented to 
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management and that management haa made decisiona regarding 
which rlaka will be accepted without additional controla being 
applied and which rlaka will be aliainated or reduced through 
the lapleaantation of controla. Manageaent decisiona should 
Include a projected tiae fraae for lapleaentation and 
dealgnation of responsibilities for iapleaentacion. In the 
ease of applications, management decisiona and lapleaentation 
guidance should be included In or be an outcome cf the 
certification process. Figure 3-1 depicts the Inter- 
relationships between the aajor activities of a DPI risk 
analysis, an application evaluatlon/certlf lea t Ion, and the risk 
aanageaent plan developaent process. 

The analysis of assets and applications froa the risk analysis 
provides the Input for the risk envlronaent section of the DPI 
RHP. The data for the sensitive application KMP should be 
found in the application sensitivity determination, security 
requirements review, and security specifications review portion 
of the application evaluation report. The threat and 
vulnerability analysis from the DPI risk analysis and the 
application system vulnerability analysis and threat scenario 
analysis provides the input to the risk categorization and risk 
occurrence evaluation sections of an RMP. The annual, loss- 
exposure phase of the risk analysis and the application threat 
scenario analysis provides the input for the risk occurvence 
impact portion of an RMP. The information required as input to 
the risk-reduction decision portion of the RMP are the risk 
analysis management decisions and the certification decisions 
concerning which controls will be implemented. 

The risk-reduction action plans will nrlmarily be based upon the 
management and certification decisions following a DPI risk 
analysis or an application evaluation/certification respectively. 
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Additional data for design, development, or procurement 
planning may be required and will be discussed below. The nest 
step Is to develop an outline of the IMP. The develo p m en t of 
DPI, application, and Center-level plans are discussed 
separately below. 

3.2 DPI Risk Management Plans 

The risk management plan for a data processing Installation 
most be Integrated with, and considered a part of, the DPI's 
computer security program. It should draw upon risk analysis 
documentation and not be a complete or substantial 
redocumentation of the risk analysis. Bather, the IMP should 
summarize the findings of the risk analysis and provide a road 
nap for achieving a security posture in which risks are 
properly managed. 

3.2.1 Risk Management Plan Framework 

The risk management plan should be Initially constructed In 
outline fora siullar to the sample provided in Appendix A. The 
major items should Include: a description of the risk 

environment, risk categorization, risk occurrence evaluation, 
risk occurrence impact, risk reduction decisions, and risk 
reduction action plans. 

3.2.2 Data Collection 


The primary source of data t^r the risk environment, risk 
categorization, risk occurrence evaluation, and the risk 
occurrence lapact is the risk analysis report and associated 
work papers. Additional sources of data for documenting the 
risk environment and risk categorization are the reports and 
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tk supporting work papers of ujr Internal audita. Inspector 
General reports, or nanagenent reviews. A list of personnel 
who were interviewed during the risk analysis and the names of 
nanagenent or operating staff who received briefings during the 
risk analysis should be compiled for use by the IMP 
developers. The IMP developers should also identify logistics 
and procurement personnel who can provide data and assistance 
for any controls that nay involve procurement activities. 

In the following discussions, references will he made to forma 
and worksheets utilised in the USi Self-Analysis Guidance 
Itocment (SAGOD) for AGP link Analysis. Where appropriate, 
relevant forms or documentation from other methodologies should 
be utilised in developing IMPs. 

1.2.3 link Environment 


This section of the DPI risk nanagenent plan should provide s 
physical, organisational, and operational description of the 
data processing installation. 

1. The physical description of the DPI should, at a 
minimum. Include the following: 

a. Building number or name 

b. Physical location on the Center (street address or 
street boundaries) 

c. Brief descrlotlon of the structure 

d. toon locations of computer hardware and peripherals 

e. Number and location of prlaary and emergency exits 

f. Location of user service areas or other public 

areas 
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g. Floor plan for each floor showing computer 
resource locations to Include coaaunlcatloos and 
aajor elec tr lea' —ipport equipment 

h. Description and location of physical security 
controls Including guard stations , access control, 
alarms, and fire protection/ suppression equipment 

I. Storage areas for combustible supplies sad media 
vaults 

J. Description of supporting utilities (e.g., pow e r, 
air conditioning, etc.) 


The above Information may be obtained from Append!* 1 
of the SAGUD risk analysis report. The primary forms 
will be the Data Collection. Form and floor plans 
included or appended to the report. 

2. The organisational description should Include the 
following: 


a. Copy of DPI mission statement 

b. DPI functional organisation chart with brief 
description of the units for both the NASA 
organisation and facilities management contractor 
where appropriate 

c. Key personnel telephone list 


Organ isatlonsl description data should be available 
from the risk analysis work papers and the Data Source 
Form found In Appendix B of the SACUD risk analysis 
report. 

3. The operational description should include the 
following: 


a. Listing of physical assets (e.g., computer 
hardware, peripherals, terminals, etc.) 

b. Hardware configuration chart 
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c. Listing of vendor aalntenance points of contsct 

d. Consunl cations schematics 

s. List of sensitive applications processed st DPI 

f. Description of procedural sod technical DPI controls 
(e.g., computer access controlled by a software 
security package that provides password protection 
to file level, etc.) 

Operational description data should be found In Appendix B on 
the Asset Inventory For*. 

If the above required data Is not available fro* the SAGOO risk 
analysis report and attendant work papers, refer to Voliaa 1 of 
the Self Analysis Guidance Document, specifically Task 1, Step 
3 .and Task 2, Steps 1-8. Existing safeguards or controls are 
discussed In Chapters 3 and 5 of the SAGUD. Existing safe- 
guards *ay also be found In the responses to the vulnerability 
questionnaire. 

3. 2. A Risk Categorization 

This section of the DPI risk eanagement plan should Identify 
the threats that aay adversely lapact the equipment, 
facilities, personnel, data, and supplies. Threats should be 
documented without reference to existing safeguards or controls 
designed to altlgate threats. The objective In docuaenting 
threats at this point in the plan is slaply to provide an 
identification and to develop an understanding of the threats 
to the equlpaent, facilities, personnel, supplies, and data. 

The potential lnpact or consequences of any threat acting 
against the DPI will be docuaenied In the risk occurrence 
lapact section of the RMP. 
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Stt||Mttd nyi of documenting threat* includa tha following: 


• Categorization by natural disasters, dlaaatera of human 
origin* access problems, and system reliability hazards 
aa discussed In NUB 2410, Appendix J, Section SO) 

o Threats by loss category; i.e., daaage, denial uf 
possession, denial of use and disclosure per SAGUD 
Voluae II, Appendix C3, or as codified la Appendix C2 

e Listing of threat deflnltiona/scenarios as provided In 
Appendix E of this docuaent 


Threat data nay be obtained froa the Threat Asset Analysis 
Matrix fora la Appendix B of the SACUD risk analysis report. 


3.2.5 Risk Occurrence Evaluation 


Each threat should be evaluated with respect to Its likelihood 
of occurrence. The nature of each threat will, in large part, 
determine the potential frequency of occurrence. In the case 
of natural disasters, geography, time of year, ataospherlc 
patterns, etc., are aajor factors In estimating likelihood. In 
dealing with threats of human origin, likelihood of occurrence 
will be based, to a significant degree, on the reliability, 
Integrity, and competency of personnel. The other aajor 
parameter affecting likelihood of occurrence will be the 
vulnerabilities of the DPI. Vulnerabilities My exist as a 
result of operational procedures, ineffective controls, or lack 
of controls. This section of the RM? should identify the 
threats, the vulnerabilities which would perolt the threats to 
aaterialize, a statement of likelihood of occurrence, and an 
identification of existing controls assigned to reduce the 
occurrence rate. In those cases where likelihood of occurrence 
is based primarily on judgmental estimates rather than 
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empirical evidence, the rationale for eha eatlaate should be 
documented. 

The primary sources of data for this section of the BMP are the 
Threat Asaet Analysis Matrix, the Threat Asset Summary Fora, 
and the Vulnerability Findings fora from Appendix B of the 
SAGOO risk analysis report. 

3.2.6 Risk Occurrence Impacts 

The impact or consequences for each threat should be assessed. 
The impact is usually stated in monetary (dollar) terms and is 
determined by multiplying the single or one-time loss of an 
asset by the frequency of occurrence of each threat that may 
adversely affect the asset. Single-time loss for damage, 
denial of possession, denial of use and disclosure are usually 
determined separately. This section of the DPI risk management 
plan should identify each asset, the threats that may impact 
the asset, the vulnerabilities that vould permit each threat to 
materialize, the annual frequency estimate for each threat, the 
single time loss, and the annual loss exposure. In those 
Instances where the oider of magnitude concepts were used due 
to difficulty in determining dollar values, a narrative 
description of the threat occurrence Impact should be included. 

The primary sources of data for this section of the BMP are the 
ALE Worksheets from Appendix B of the SAGUD risk analysis 
report. 

3.2.7 Risk Reduction Decisions 


The previous sections of the DPI risk management plan have 
Involved extracting and/or summarizing data previously 


documented la tha risk analysis report. Tha development of 
tlus action of the report Is based on management's response to 
the risks Identified and analyzed In the risk analysis and the 
control recommendations resulting from the risk reduction 
analysis. 

Bach risk should be Identified, the impact of risk occurrence 
on the organisational mission should be described, and the 
acceptability or nonacceptablllty of the risk should be 
indicated. For unacceptable risks, the controls currently in 
place as well as those approved by management for later 
implementation should be noted. 

3.2.8 Klsk Reduction Action Plans 


Management's decisions should be turned into a set of action 
plans for implementing the needed controls. The data for the 
action plans should be contained In or attached to the decision 
paper originally provided to management. The action plans 
should provide detailed activities for the design, development, 
procurement, testing, and Inplementation of controls. At a 
minimum. It is recommended that a GANTT chart be developed 
indicating elapsed time to implmentatlon, with subtask 
schedules Included. Project documents should permit the 
tracking of subtasks as well as resource expenditures. A 
sample risk reduction action plan for developing a contingency 
plan is shown in Figure 3-2. 

3.3 Sensitive Application Risk Management Plans 

The risk management plan for a sensitive application draws upon 
the data gathered and the analytical results documented during 


3-11 



PROJECT STATUS REPORT 
RISK REDUCTION ACTION PLAN 
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PROJECT STATUS REPORT RISK REDUCTION ACTION PLAN 
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the evaluation/certification process. As In the case of a DPI 
IMP, tha sensitive application RHP should, where possible, 
summarize the findings of the evaluation. The sensitive 
application IMP should provide a roadaap for achieving an 
unqualified certification of each sensitive application. 

3.3.1 Risk Management Plan Praoework 

Tha risk management plan should be initially constructed in 
outline fora similar to the outline saaple shown in 
Appendix B. The aajor lteas to be included ares the 
application risk environaent, risk categories, risk occurrence 
evaluation, risk occurrence impact, risk reduction decisions, 
and risk reduction action plans. 

3.3.2 Data Collection 


The primary source of data for the risk environaent, risk 
categorization, risk occurrence evaluation, and the risk 
occurrence impact is the application evaluation report. 
Additional data may be gathered from system documentation. 
Audit and 16 reports, and management reviews. Lists should be 
compiled of the personnel who were interviewed during the 
evaluation and also of the personnel who participated in the 
threat scenario analysis sessions. The risk manageaent plan 
developer should identify the procurement personnel who are 
responsible for acquisition of ADP software and services. 

In the following sections, references will be made to 
activities and forms utilized in the evaluation of existing 
sensitive applications, as described in "Guidelines for 
Certification of Existing Sensitive Applications'* (MTR- 
82W0018)., Relevant forms or documentation from other 


3-13 



methodologies should be substituted in the development of BMPs 
as appropriate. 

3.3.3 Risk Environment 

This sectloo of the sensitive application risk management plan 
should provide a general description of the application, the 
data, the security concerns, and the existing controls. The 
general description of the application should be available from 
Section 2 of the Evaluation Report. The general description of 
the application should, at a minimum. Include the following : 

e A functional overview of the application 

e List of major users, data owners and data custodians, 
and the application CSO 

e A description of the DPI that processes the application 

e A description of the mode(s) of execution (i.e., batch, 
on-line, update, remote Job entry, etc.) 

* Magnification of software package vendor (if 

appropriate) and a description of maintenance procedures 

e. A description of the sensitive or critical attributes 
of the application 

e The type of data processed and generated by the 
application 

e Description of any sensitive or critical processing 
algorithms 

e List of other applications that utilize or require data 
from this application 

The description of the security attributes should include the 
following: 

e The data and system security objectives 
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• The security requirements end specifications 

s Any existing security controls, including physiesl end 
technicsl safeguards and administrative procedures 

3.3.4 Risk Categorization 


This section of the sensitive application risk management plan 
should identify the threats that may adversely impact the 
integrity, confidentiality, or availability of the application 
and its associated data. Threats should be documented without 
regard to any existing or planned safeguards. The objective is 
simply to identify those events, situations, or personnel (by 
position) that have the capability to Impact adversely the 
functions and data supported by the application. The potential 
impacts or consequences of any threat or threats acting against 
the application system as well as the effectiveness of any 
'mxlstlng controls in mitigating these threats will be 
documented in the risk occurrence evaluation and Impact 
sections of the RMP. The data for this section of the RMP 
should be extracted from the threat scenario analysis worksheet. 

Suggested ways of documenting threats Include: 


e Categorization by threats to the application software 
(e.g., software development and maintenance, threats 
during program execution) 

e Categorization of threats to data (e.g., during data 
preparation or entry, data base maintenance) 

e Categorization of threats to output products (e.g., 
during distribution, storage or destruction operations) 
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• Lilting of threats by security objective; i.e, 
Integrity, confidentiality, availability, and 
deliberate or unintentional acts) 

• Categorization by threats to security requirements 


3.3.5 Risk Occurrence Evaluation 


This section should document the likelihood that each threat or 
threat scenario will occur. Each threat or threat scenario 
should be Hated, together with the vulnerabilities that would 
permit an attack to be mounted against the system, and a 
description of the controls that are in place to prevent or 
limit loss. The likelihood of threat occurrence should then be 
stated in high, medium, or low terms with an accompanying 
description of the rationale for this evaluation. 

The primary source of data for this section of the report are 
the Threat Analysis Worksheets. 

3. 3. ft Risk Occurrence Impacts 

This section of the report should state the monetary impact of 
a successful attack against the application and/or data. Where 
it is not possible or feasible to quantify the Impact, a 
qualitative statement or narrative description of the 
consequences of a successful attack against the application and 
the associated data should be provided. 

The primary source of data for this section of the RHP are the 
Threat Analysis Worksheets. 
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3.3.7 Riak Reduction Decision 


The previous sections of the sensitive application risk 
management plan have involved the extraction and summarization 
of data from the sensitive application evaluation report. This 
section will be based upon the certification report provided to 
and the certification decision made by the application G>0. In 
this section of the RHP, each risk should be identified, the 
impact or consequencea on the organizational missions should be 
described, and * notation should Identify each risk as 
acceptable or not acceptable. For unacceptable riskz, the 
controls currently in place as well as those approved by 
management for implementation should be noted. 

3.3.d Risk Reduction Action Plans 


The successful implementation of additional safeguards for an 
existing application requires the development of one or more 
plans to provide control over design, development, procurement, 
and testing activities. The expenditure of dollar &r.d 
personnel resources should also be monitored The data for the 
action plans should be contained in the supporting documents 
for the deci'iion paper submitted, as appropriate, to the 
application C:>0 or upper managment. At a minimum, a simple 
GANTT chart should ’_>» prepared. This chart auould Indicate 
elapsed time for implementation and provide subtask trchedules. 

A sample risk reduction action plan form la provided In 
Appendix F. (See Figure 3-2 for a completed example.) 

3.4 NASA Center-Level Risk Management Plana 

Center computer security official 1 : should develop risk 
management plans that summarize ADP security risks across the 
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entire Cev..er. The primary objective of the Center-level risk 
management plan la to provide a management control proceaa over 
DPI and sensitive application risk management plans. A 
secondary objective of the Center risk management plan is to 
provide the Center CSO with a mechanism to monitor the DPI and 
sensitive application risk management activities. 

3.4.1 Risk Management Plan Framework 

The Center-level risk management plan should be started in 
outline form similar to the sample provided In Appendix C. The 
major items in the outline should include: a description of 

the risk environment, risk categorization, risk occurrence 
evaluation, risk occurrence consequences, risk reduction 
decisions, and risk reduction action plans. It is recommended 
that separate subsections be established for DPI's and 
applications within each major section.’ 

3.4.2 Data Collection 


The primary sources of data for the Center risk management plan 
are the DPI and sensitive application risk management plans. 

The Center computer security official should also have access 
to Center- wide audits, IG reports, and management review*. 

3.4.3 Risk Environment 


This section of the Center risk management plan should provide 
physical, organizational, and operational description of the 
Center's data processing environment. The physical description 
of the Center should include: 
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• Description of geographical location of the Center to 
include sajor metropolitan area(a) surrounding the 
Center 

e Description of primary and secondary sources of 
electric power, telephone and other coemuni cat ions 
service, beating and cooling 

e Physical location of utility distribution points at the 
Center 

The organisational description of the Center should include the 
following: 


e i Center niaaion statement 

m A summary of Che major type of activities conducted at 
the Center 

e A functional organization chart that Identifies major 
directorates at the Center 

e A telephone listing of ^ey management and operational 
personnel who have ADP and security responsibilities 
and also a telephone listing of DPI and sensitive 
application CSOs. 


The operational description should include the following: 


o Description of the open or closed nature of the Center 
(e.g.. Center Is open to visitors through Cate 1 during 
daylight hours with restricted access during hours of 
darkness) 

a General description of Center security program such as 
the physical security procedures for employees, badge 
requirements, perlaeter controls, etc. 


3. A. 3.1 Data Processing Installations 


This portion of the risk environment section should Include the 
following for each DPI: 


3-19 



• The location 

o the primary functional uses (e.g., lnatltutlonal data 
process lag. mission control, etc.) 

o A functional organisation chart which Identifies DPI 
managers 

o The name and phori number of the DPI CSOs 

n The date ana major findings of the last DPI risk 
analysis 

3.*. 3. 2 Sensitise Applications 

This portion of the risk environment section should Identify 
the sensitive applications processed at the Center. For each 
sensitive application the following Items should be documented: 

e The overall functional purpose of the application 

o The DPI at which the application is processed 

o The node of execution (l.e. , batch, on-line query, 
remote Job entry) 

o The type of data processed 

a The name and telephone number of the application CSO 
and data owner 

• The date of last evaluation and any qualification 
contained in the certification atateaeat 

3.4.4 Risk Categorization 

This section of the Center risk management plan should identify 
the threats that may adversely affect Center-wide ADP 
operations. Threats should be listed in this section without 
regard to any existing or planned safeguards. For suggested 
ways of categorizing or listing threats refer to Sections 3.2.4 



and 3.3.4 of this document. This oectloo should bo a 
MMTlutiM of the DPI and sensitive application tiak 
categorization sections. 

3.4.3 tisk Occurrence Evaluation 

Bach Center-wide threat should be evaluated with re to 
likelihood of occurrence. This section of the Center risk 
management plan abould Identify each threat, the 
vulnerabilities that eight permit the threat to eater ialize, 
the controls or safeguards designed to reduce the likelihood of 
occurrence, and a stateaent indicating likelihood of 
occurrence. In those instances where likelihood of occurrence 
is primarily based on judgmental estimates rather than 
empirical evidence, the rationale for the estimate should be 
documented. Again, this section should be built on 
corresponding sectlonc in the DPI and sensitive application 
IMPS. 


3.4.4 Risk Occurrence Impacts 


The impact or consequences for each threat should be assessed. 
The impact should be stated in dollar terms. Consequences 
should be stated in qualitative terms. Ac the Center- level, 
most impacts to Center-wide ADP operations should be described 
in terms of consequences. Detailed statements of impact are 
not recommended for the Center-level risk management because 
the impact on each DPI or application will be contained in 
individual DPI and application RMP'a which should be svailable 
to the Center CSO. 
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3.4.7 Risk Reduction Decision! 


This section of Center-level risk unigeseat plan should 
summarize the management's ADP security program decisions. It 
should Indicate the guidance that management has provided for 
reducing ADP security risks at the Center-level. For example, 
a Center manageme . decision to have all DPIs conduct an 
initial risk analysis within the next two years would be 
included in this section of a Center SMP. 

3.4.8 Risk Reduction Action Plans 

Management's decisions concerning Center-wide ADP security 
risks should be turned Into a set of action plans. Each action 
plan should Identify the najor task and subtasks, the estimated 
and elapsed time to completion, the responsible person, and the 
estimated and actual resource expenditures. It is suggested 
that a GANTT chart be developed similar to the example in 
Figure 3-2. 

3.5 Integration of DPI and Sensitive Application Risk 
Management Plane 

In some NASA environments, it may be desirable to integrate the 
DPI and sensitive application risk management plane Into a 
single document. This would apply In a case where a single 
sensitive application is the only application processed on a 
stand-alone micro or mini computer. Integration of plans nay 
also be appropriate where ADP security risk management 
responsibilities for both the DPI and a sensitive application 
are assigned to a single computer security official. 

Separation of DPI and sensitive application specific data 
should be maintained In the RMP sections addressing the risk 
environment, risk categorization, risk occurrence evaluation, 
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and rick occurrence impact. However, Integration of the rick 
reduction action plana la appropriate where one individual la 
raeponalble for managing the rlaka aaaociated with both the DPI 
and the sensitive application. 

3.6 Coordination of DPI and Sensitive Application 
Risk Management Plans 

Although the above guidance has made a distinction between DPI 
and sensitive application risk management plans, it is obvious 
that computer facilities and applications are interdependent. 

It is, therefore, important to maintain close liaison between 
the personnel who develop and maintain DPI and sensitive 
application risk managment plans. Coordination of rir i 
reduction action plans la of special concern where the measures 
retired to reduce the risks in an application system are 
dependent upon technical features inherent to the computer 
hardware or the operating system software. 

3.7 Sensitivity of Risk Management Plans 

Risk managment plans, like risk analysis reports, provide a 
consolidated statement of the security posture of a data 
processing installation or a sensitive application. The 
information contained in the RMP is extremely valuable to 
personnel whose interests and objectives are inimical to those 
of NASA. Therefore, the number of copies of risk management 
plans and any associated work papers should be limited. The 
distribution of copies should be tightly controlled. Copies 
should not be lefc on shelves or desk tops unattended. 
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4. RISK MANAGEMENT PLAN MAINTENANCE 


Thm maintenance of risk management plana should be focused on 
three major areas: 

1. Monitoring of risk reduction actions plaus to ensure 
that the design, development, procurement and 
implementation of controls proceed according to 
schedule and within budget 

2. Auditing of implemented controls to determine their 
effectiveness 

3. Reviewing physical, organisational and operational 
activities to Identify changes that might necessitate 
re-evaluation or modification of current risk 
reduction measures 


4.1 Monitoring of Risk Reduction Action Flans 

The actions preceding the implsmentatlon of some controls may 
closely parallel a system acquisition life cycle. For example, 
procurement sod Installation of an access control software 
package may involve several months of procurement activities, 
several months of developing access rules or matrices, 
training, testing, and phased implementation. Some controls, 
such as an ADP contingency plan for a major computer facility, 
will require as much as six months to a year for the 
development phase. Therefore, risk reduction action plans must 
be continually monitored to ensure that schedules are adhered 
to as closely as possible and that deviations from the schedule 
are reasonable and approved by management. It is also 
important to ensure that management is periodically informed on 
the progress of the action items. Normal project control 
procedures should be used for monitoring risk reduction action 
plans. 
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4.2 Audit of Implemented Controls 


The primary purpose of auditing Implemented controls Is to 
determine their effectiveness. Zt should be remembered that If 
a control is totally effective, the specific risk being 
protected probably vlll not materialize. Similarly, if the 
vulnerability being mitigated by control has not been 
exploited, the risk may not materialize. Controls must be 
audited to ensure that they operate as designed. Controls 
should be periodically tested. Documented procedures for using 
the control should be reviewed to ensure that they are being 
followed. As part of an effectlvess audit., controls should be 
evaluated to determine If the control has created a sure 
serious vulnerability or risk than It was designed ro reduce. 

4.3 Kevlewlng Physical, Organizational and Operational 
Activities 


A risk management plan Is a management tool that must be able 
to respond to changes In the physical, organizational, and 
operational environment. Changes to physical facilities, the 
Introduction of a new computer system, implementation of new 
systems, and promulgation of new regulations may affect the 
risk environment. New risks may appear and some risks may 
disappear, thus negating the requirement for some controls or 
establishing a requirement to modify existing controls. 
Organizational changes may result in changes of responsibility 
for control implementation and maintenance activities. 
Additionally, control technology Is constantly advancing which 
may reduce the cost of controls which were not previously 
considered to be cost-effective. 
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All of Cho foregoing changes should be aonltored by risk 
management plan developers. In those instances where a change 
is considered significant, Modifying current controls should be 
evaluated against the need to update the most recent DPI risk 
analysis or sensitive application evaluation. Furthermore, the 
development and implementation of risk management principles, 
techniques, and tools in the data processing environment will 
be a new experience for many NASA personnel. As experience is 
gained, progressive interaction of risk management plana and of 
these guidelines will be required. 
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APPENDIX A 


OUTLINE FOR 

DPI RISK MANAGEMENT PLAN 


1. INTRODUCTION 

1.1 Purpose 

1.2 Background 

2. RISK ENVIRONMENT 

2.1 Physical Description 

2.2 Organization Description 

2.3 Operational Description 

3. RISK CATEGORIZATION 

3.1 Damage Threats 

3.2 Denial of Possession Threats 

3.3 Denial of Use Threats 

3.4 Disclosure Threats 

4. RISK OCCURRENCE EVALUATION 

4.1 Damage Threats 

4.2 Denial of Possession Threats 

4.3 Denial of Use Threats 

4.4 Disclosure Threats 

5. RISK OCCURRENCY IMPACTS 

5.1 Iapact/Consequences of Damage Threats 

5.2 Impact/Consequences of Denial of Possession Threats 

5.3 Iopact/Consequences of Denial of Use Threats 

5.4 Imp ' 't/Consequences of Disclosure Threats 

6. RISK R i CTION DECISIONS 

6.1 Acceptable Risks 

6.2 Unacceptable Risks 

7. RISK REDUCTION ACTION PLANS 

7.1 Project Plan for Risk Reduction Action Item 1 

7.2 Project Plan for Risk Reduction Action Item 2 
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APPENDIX B 


OUTLINE FOR 

SENSITIVE APPLICATION RISK MANAGEMENT PLAli 


1. INTRODUCTION 

1.1 Purpose 

1.2 Background 

2. RISK ENVIRONMENT 

2.1 General Description 

2.1.1 Functional Overview 

2.1.2 Users, Owners, Custodians, CSO 

2.1.3 Description of Hardware Support 

2.1.4 Type of Data Processed 

2.1. 5 Sensltlve/Crltlcal Attributes 

2.1.6 Sensltlve/Crltlcal Algorithms 

2.1.7 Associated Application Systems 

2.2 Security Attributes 

2.2.1 Data and System Security Objectives 

2.2.2 Security Requirements 

2.2.3 Security Specifications 

2.2.4 Existing Controls 

3. RISK CATEGORIZATION 

3.1 Integrity Threats 

3.2 Confidentiality Threats 

3.3 Availability Threats 

3.4 Fraud Threats 

4. RISK OCCURRENCE EVALUATION 

4.1 Integrity Threats 

4.2 Confidentiality Threats 

4.3 Availability Threats 

4.4 Fraud Threats 

5. RISK OCCURRENCE IMPACTS 

5.1 Impact/Consequences of Integrity Threats 

5.2 lopact/Consequences of Confidentiality Threats 

5.3 Impact/Consequences of Availability Threats 

5.4 Iapact/Consequences of Fraud Threats 
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RISK REDUCTION DECISIONS 


6.1 Acceptable Risks 

6.2 Unacceptable Risks 

7. RISK REDUCTION ACTION PLANS 

7.1 Risk Reduction Action Iten 1 

7.2 Risk Reduction Action Item 2 

7.3 Risk Reduction Action Iten 3 
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APPENDIX C 


OUTLINE FOR 
NASA CENTER 
RISK MANAGEMENT PLAN 


INTRODUCTION 

1.1 Purpose 

1.2 Background 

RISK ENVIRONMENT 

2.1 Physical Description of Center 

2.2 Organizational Description of Center 
2.5 Operational Description of Center 

2.4 Data Processing Installations 

2.4.1 DPI Locations 

2.4.2 DPI Functions 

2.4.3 DPI Orgnlzatlon 

2.4.4 DPI CSO 

2.4. 5 Date and Major Findings of Last DPI Risk Analysis 

2.5 Sensitive Applications 

2.5.1 Functional Overview of Applications 

2.5.2 Supporting DPI 

2.5.3 Type of Data Processed 

2.5.4 Application CSO and Data Owner 

2.5.5 Date of Last Evaluation and Qualifications to 
Certification 

RISK CATEGORIZATION 

3.1 Threats to Data Processing Installations 

3.1.1 Damage Threats 

3.1.2 Denial of Possession Threats 

3.1.3 Denial of Use Threats 

3.1.4 Disclosure Threats 

3.2 Threats to Sensitive Applications 

3.2.1 Integrity Threats 

3.2.2 Confident! jlity Threats 

3.2.3 Availability Threats 

3.2.4 Fraud Threats 



4. R1SU OCCURRENCE EVALUATION 

4.1 Threats to Data Processing Installations 

4.1.1 Damage Threats 

4.1.2 Denial of Possession Threats 

4.1.3 Denial of Use Threats 

4.1.4 Disclosure Threats 

4.2 Threats to Sensitive Applications 

4.2.1 Integrity Threats 

4.2.2 Confidentiality Threats 

4.2.3 Availability Threats 

4.2.4 Fraud Threats 


S. RISK OCCURRENCE CONSEQUENCES 

5*1 Threats to Data Porcessing installations 


5.1.1 Consequences of 

5.1.2 Consequences of 

5.1.3 Consequences of 

5.1.4 Consequences of 

5.2 Threats to Security 

5.2.1 Consequences of 

5.2.2 Consequences of 

5.2.3 Consequences of 

5.2.4 Consequences of 

6. RISK REDUCTION DECISIONS 

6.1 Acceptable Risks 

6.2 Unacceptable Risks 

7. RISK REDUCTION ACTION PLANS 


Damage Threats 

Denial of Possession Threats 
Denial of Use Threats 
Disclosure Threats. 

Integrity Threats 
Confidentiality Threats 
Availability Threats 
Fraud Threats 


7.1 Risk Reduction Action Item 1 

7.2 Risk Reduction Action Item 2 

7.3 Risk Reduction Action Item 3 
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